home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 12⁄1⁄89 / 0347-Re MacApp & Projecto-Jan90 < prev    next >
Encoding:
Text File  |  1990-01-12  |  4.0 KB  |  85 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  JAIME1       to B.CHENG
  2.  
  3. Item    7086927                         6-Jan-90        16:50
  4.  
  5. From:   SATORI                          Satori SW, Hugh Rogovy,PRT
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    Re: MacApp & Projector
  10.  
  11. James,
  12.  
  13. We have been using Projector with a four programmer team and 100+
  14. units/resource files for about a year, now.  I have been really pleased with
  15. the way it has worked out for us.  In fact, I'm not sure how a multi-programmer
  16. team could get much programming done without it. In the past, with the same
  17. number of programmers, we spent so much time figuring out which files needed to
  18. be updated and who touched what that, at times, it took 3-4 hours just to do a
  19. complete integration of everyone's code changes for a week. Also, while we were
  20. doing the integration, it got to the point that no one could make changes to
  21. any source code while the integration was in progress.  Pretty inefficient use
  22. of time, if you ask me.
  23.  
  24. Now, with Projector, integrating source code is a pretty trivial task.  I would
  25. guess that we spend no more than an hour a week per programmer merging source
  26. code into the main trunk of an app (probably less).  Also, no one has to stop
  27. working while another programmer is integrating code, because multiple versions
  28. of each file are kept.  And the current version of the app is much more up to
  29. date.
  30.  
  31. A couple if caveats/hints however:
  32.  
  33. Projector files never shrink
  34.     We've found that the best way to deal with this is to, at times, just
  35. delete the entire project and then create a new project with the latest trunks.
  36. The disadvantage in this approach is that one cannot keep a "complete" history
  37. of "all" changes made to a specific unit.  This really isn't that much of a
  38. problem, though, because there can't be all that much value in keeping early
  39. versions of a unit that's been through 20 or 30 revisions (especially when the
  40. changes are generally "additions" to a unit).
  41.  
  42.     Some of the projector tools/scripts have problems with space characters in
  43. path/file names.  I think this is due to the fact that some of the scripts
  44. don't have shell variables quoted like they should.  We found it a lot easier
  45. to change "Hard Disk" to "HardDisk", rather than going through and correcting
  46. all of the scripts.
  47.  
  48.     I feel that a good way to set up your projects is to create as many
  49. projects as there are pertinent folders on the workstation.  For example we
  50. have projects for "MacApp Interfaces", "MacApp Libraries", "User Libraries",
  51. and each application.  This is nice because you can set the checkout directory
  52. for each workstation in UserStartup and eliminate the need to specify "where"
  53. checked-out files should go every time you do a checkout.  I'm not sure that
  54. Dale's suggestion of creating a separate project for each class implemention
  55. would have been such a good idea for us, as we have such a huge number of
  56. in-house classes.  For smaller projects, though it would probably be fine.
  57.  
  58.     A good way to do "major" check-ins is for the programmer doing the check-in
  59. to check-out trunks for each branch he'll be merging.  Merge all of the
  60. branches in and then check all of the trunks in at one time.  This eliminates
  61. partial check-ins which usually hang everyone else up if they checkout newer
  62. while the programmer doing the check-in still has unfinished trunks
  63. checked-out.
  64.  
  65.     Also, at one point we had projector set up on one poor guy's computer with
  66. Tops.  This wasn't so bad for everyone else, but it really became an irritant
  67. to the guy we "volunteered" to keep the projects, when everyone started
  68. accessing the projects.  I highly recommend a dedicated server (preferably
  69. AppleShare), although I'm sure you guys already have that.
  70.  
  71. Overall, I would say that Projector has increased our efficiency on
  72. multi-programmer projects far more than I would have guessed before we started
  73. using it.
  74.  
  75. Sorry this link is so long, everyone…(especially since it only has a limited
  76. relation to MacApp per se).
  77.  
  78. Good Luck,
  79.  
  80. Chris Le Croy
  81. Satori Software
  82. AppleLink SATORI
  83.  
  84.  
  85.